Hacking Christmas Gifts: Brushing with a Bluetooth Toothbrush
If high-tech gadgets are on your holiday shopping list, it is worth taking a moment to think about the particular risks they may bring. Under the wrong circumstances, even an innocuous gift may introduce unexpected vulnerabilities. In this blog series, VERT will be looking at some of the Internet’s best-selling holiday gifts with an eye toward their possible security implications. Some of the risks discussed in this series may be over the top and even comical, while others may highlight realistic problems you may not have considered.
Over the years, I have seen quite a few seemingly absurd Bluetooth integrations into everyday products. Whether it is the “smart” hairbrush that listens to your hair or the toaster which gives a phone notification when the toast is ready, these inventions are a good reminder that not every household item needs to be connected. The toothbrush is definitely one of these devices that doesn’t need more computing power.
At least that’s what I thought until I accidentally bought some. After deciding it was time for the kids to have rechargeable electric toothbrushes, I ordered the Philips Sonicare for Kids on a whim and was rather surprised when they arrived sporting a Bluetooth logo.
Although I must admit I initially considered returning them unopened, my curiosity got the better of me, and I decided to have a closer look. The first and most obvious question, of course, is: what in the world does a toothbrush need with Bluetooth? It turns out that the brush is tied to a smartphone app that adds a game on top of brushing teeth. Within the game, the child is the adoptive parent of a cuddly creature who needs help brushing.
When the brush is activated, the app displays an animation to help the child learn how to brush and properly pace themselves. The child is rewarded with in-game presents and periodic achievement awards. The app also gradually increases the duration and intensity of brushing sessions as time goes on until the child is used to a full 2-minutes at the full strength of the brush.
The next day, I loaded the app on a spare Android device I tend to use for product testing. The first thing that happens when loading the Android app is that it asks for access to your local device file system; if the permission is rejected, the app will fail to start. If the permission is accepted, the user is prompted to create a kid profile.
You can upload a photo from your device or capture an image from the camera, but using the camera will require allowing the app access to take pictures and record video. It is unclear whether the shared storage access is required simply for finding photos on the SD card or if there may be some other functionality requiring this.
After a few days of use, my concerns with the permissions model grew to a new level when the app asked my child to allow the app access to the microphone. It turns out that the Sonicare for Kids app unlocks new features as rewards for continued brushing. One of these features is a mode where the creature will listen to the child and repeat what it hears in a funny voice.
A megaphone icon appears to control this feature, and when it is enabled for the first time, Android prompts the user about whether the microphone should be allowed. This is a typical Android behavior, but it definitely doesn’t sit well with me in this type of kid-focused app. A parent must set up the app for the child, and there is a PIN-protected parent dashboard within the app, yet the app inexplicably leaves this privacy decision to the child.
Application permission decisions should not be left for the kids to decide but rather the parent. On first load, apps like this should explain how each permission is used and give parents permission to accept or deny each ahead of time. Changes to these settings should be done in the PIN-protected parent mode and not during playtime.
Moving past that and ignoring the inevitable problems that come from a child looking down toward a screen while brushing teeth, I have to admit that it did help get the kids more excited about brushing. While using the device, I made a couple observations about the way it operates including some possible technical flaws:
- The app is flaky.
- It frequently loads the wrong kid profile.
- It often thinks you got a new toothbrush.
- It does not work when two toothbrushes are on and nearby.
- Information flows in all directions.
- Running the brush before the app is connected decrements the brush timer.
- The app seems to specify the brush duration and intensity when connected.
- The toothbrush sends observable BLE beacons if either button is pressed.
These limitations open the door for a rather trivial denial-of-service attack. An attacker could prevent someone from using the app with their brushing by simply having another toothbrush nearby.
Even without the toothbrush, the Bluetooth Low Energy (BLE) device itself can likely be spoofed using readily available tools. That being said, I’m not sure how many “attackers” there are out there (besides a bratty sibling or two) with an interest in interfering with a kids’ tooth brushing.
The greater risk I see, stemming from the toothbrush’s Bluetooth interface, is that of information disclosure. Each time the toothbrush is used, whether with the app or without, it is transmitting Bluetooth beacons for anyone nearby to observe.
These beacons act as an information disclosure weakness, allowing someone outside the home to know when teeth are being brushed. A simple Bluetooth logging device left outside a home can easily recognize if a household has a regular routine. Although this isn’t exactly top-secret information, it definitely could hold value to a criminal performing reconnaissance before a break-in.
Further inspection of the toothbrush’s Bluetooth services may also reveal other sensitive information, but from what I can tell, it is unlikely that anything of interest is really stored on the device itself.
Beyond the risk of information disclosure, the app permissions along with the Bluetooth interface certainly raises the possibility (although unlikely) of a further device compromise through the toothbrush. If the app does not safely handle all incoming data, it could become trivial for an adversary to spoof a toothbrush that sends malicious responses.
The likelihood of this largely depends on what, if any, data is being transmitted from the toothbrush back to the app. Because of the broad permissions described above, a compromise of the toothbrush app would also allow the attacker to access the phone’s local storage and possibly also the camera and microphone.
Android app permissions can potentially be hijacked by other apps on the device through unintentionally exposed Intents or operating system weaknesses. Based on a quick monitoring of the app’s traffic (using HttpCanary), it is also sharing advertisement tracking details with Facebook. This is not generally something I like to see, especially in an app made for kids, but that’s a matter for another post.
Overall, I’m still of the mindset that toothbrushes really don’t need apps or Bluetooth, but at the same time, I also can’t say that I didn’t find some value in my children being more motivated to brush.
While I don’t see this device as a large security or privacy problem, it does have its share of smaller ones. Some of the problems are fundamental to the design, while others can be mitigated or eliminated through relatively simple changes. From my perspective, the most basic step the vendor could take to improve this situation would be to simply restructure and clarify the permissions requested.
They may have a very good reason for needing access to the shared device storage, and if so, they should make this clear to the user before requesting the permission. Further, permissions which may not be needed until the child is using the app for playtime should be requested up front along with information for parents. At the end of the day, though, I rate this product in the category of “questionable need” more so than “questionable security.”
